Namespace Management Techniques for Facilitating Multi-Cluster Application Development

ABSTRACT

Techniques for managing namespaces in a multi-cluster management (MCM) system to facilitate multi-cluster application development are provided. In one set of embodiments, a computer system executing the MCM system can create a workspace for an application being developed by a software development team of an organization, where the workspace is a logical grouping of namespaces on which the application has been or will be deployed, and where at least a subset of the namespaces can belong to different clusters of the organization. The computer system can then assign a member of the development team as a workspace administrator of the workspace, thereby enabling that development team member to perform management tasks on the workspace and its member namespaces via the MCM system (e.g., creating and adding namespaces to the workspace, setting access/image/network policies on the workspace, etc.), without help from the organization&#39;s IT staff.

BACKGROUND

Kubernetes is an open-source software platform for orchestrating thedeployment, scheduling, and scaling of containerized applications (i.e.,software applications whose program code and dependencies are packagedinto a standardized format, known as a container image, that can beuniformly run in different computing environments). A Kubernetes clusteris a group of physical or virtual machines on which an instance of theKubernetes platform and the containerized applications it orchestratesare placed and run.

For high availability and other reasons, it is becoming increasinglycommon for organizations to develop containerized applications that aredeployed across multiple Kubernetes clusters rather than on a singlecluster. The development of such an application (referred to herein as a“multi-cluster application”) involves, among other things, the creationof a namespace for the application in each target cluster (whichprovides a unique resource/object scope for the application within thatcluster), and the setting of certain policies on those namespaces (whichallows, for example, the application's development team members toaccess the namespaces and deploy their application objects therein).

However, existing systems for managing an organization's Kubernetesclusters (referred to herein as “multi-cluster management (MCM)systems”) generally do not permit the organization's developers tocreate namespaces or set namespace policies on their own, as these aretraditionally considered infrastructure tasks to be carried out byinformation technology (IT) staff. In addition, such existing systemsgenerally do not provide a mechanism for efficiently managing arbitrarygroups of namespaces that may belong to different Kubernetes clusters.As a result, if a development team is developing a multi-clusterapplication that requires, e.g., the creation of five new namespaces infive different clusters and the setting of a particular access policy onthose five namespaces, the development team must submit one or moresupport requests to the IT department and wait for a response. An ITstaff member assigned to the request(s) must then create the fivenamespaces and set the correct access policy on each individualnamespace on behalf of the development team, which is an inefficient anderror-prone process.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an example operating environment according to certainembodiments.

FIG. 2 depicts a conventional multi-cluster management (MCM) data model.

FIG. 3 depicts an architecture for an MCM system according to certainembodiments.

FIG. 4 depicts a workspace-enabled MCM data model according to certainembodiments.

FIG. 5 depicts a workflow for creating a workspace according to certainembodiments.

FIG. 6 depicts a workflow for creating and adding a namespace to aworkspace according to certain embodiments.

FIG. 7 depicts a workflow for setting an access policy on a workspaceaccording to certain embodiments.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousexamples and details are set forth in order to provide an understandingof various embodiments. It will be evident, however, to one skilled inthe art that certain embodiments can be practiced without some of thesedetails or can be practiced with modifications or equivalents thereof.

1. Overview

Embodiments of the present disclosure are directed to techniques thatcan be implemented by a multi-cluster management (MCM) system formanaging groups of namespaces in an organization in a manner thatstreamlines the organization's development of multi-clusterapplications. As used herein, a “namespace” is a logical entity thatprovides a unique scope for resources and objects in a Kubernetescluster, such that any resources/objects residing in a particularnamespace will not be accessible from the context of other namespaces inthe same cluster. Accordingly, namespaces can be understood as amechanism for sharing a Kubernetes cluster among multiple tenants or usecases in a way that prevents one tenant/use case's actions frominterfering with the cluster settings and environment of another.

At a high level, the techniques of the present disclosure are based onthe novel concept of a “workspace,” which is a logical grouping ofnamespaces that may include namespaces from any Kubernetes cluster of anorganization (e.g., a first namespace N1 from a cluster C1, a secondnamespace N2 from another cluster C2, and so on). When a developmentteam of the organization is tasked with creating a multi-clusterapplication to be deployed across the organization's Kubernetesclusters, the MCM system can create and assign a workspace for theapplication to that development team. The development team can then useself-service workflows provided by the MCM system to, e.g., create newnamespaces in the organization's various clusters for its application,add the created namespaces to the workspace, and set various policies onthe workspace (which will be automatically propagated to each membernamespace), all without any, or with only minimal, assistance from IT.Thus with these techniques, the inefficiencies and other issues inherentin managing namespaces for multi-cluster application development usingexisting MCM systems (such as the need for developers to ask IT staff toperform namespace-related operations on their behalf and the inabilityto manage namespaces across clusters as a single logical unit) can beavoided.

The foregoing and other aspects of the present disclosure are describedin further detail below. It should be noted that while the presentdisclosure focuses on Kubernetes and Kubernetes clusters for ease ofexplanation, the same concepts may be applied to facilitatecross-cluster namespace management with respect to any other type ofcontainer orchestration platform that supports namespaces (or asubstantially similar construct). Accordingly, all references to“Kubernetes” herein may be substituted with the more generic term“container orchestration platform.”

2. Example Operating Environment and Solution Architecture

FIG. 1 depicts an example operating environment 100 comprising an MCMsystem 102 in which embodiments of the present disclosure may beimplemented. As shown, MCM system 102 is communicatively coupled with anumber of Kubernetes clusters 104(1)-(N) that are owned by anorganization 106. Further, MCM system 102 is accessible by a set ofusers 108 in organization 106 for carrying out various management taskswith respect to clusters 104(1)-(N), such as managing cluster andnamespace lifecycles, setting cluster-level and namespace-level featuresand policies, and so on.

In one set of embodiments, MCM system 102 may be deployed on one or morephysical or virtual machines that are located on-premises with respectto organization 106, such as at a data center that is owned and operatedby the organization. In other embodiments, MCM system 102 may be hostedin a public or private cloud and maintained by, e.g., a third-party SaaS(Software-as-a-Service) provider. Similarly, each Kubernetes cluster 104may be deployed on-premises with respect to organization 106 or hostedoff-premises in a public or private cloud environment.

For discussion purposes, assume that a development team T oforganization 106 is tasked with creating a multi-cluster application Awhich will be deployed across clusters 104(1)-(N) for, e.g., highavailability, low end-user latency, and/or other reasons. As noted inthe Background section, in this scenario there is a need for developmentteam T to (1) create an application-specific namespace for A in eachcluster, as that will provide a unique resource/object scope for A whichis isolated from other applications/tenants in the same cluster, and (2)set various policies on those namespaces (e.g., access, image, andnetwork policies) that are pertinent to the development and/or operationof A.

However, existing MCM systems are not designed to efficiently support(1) and (2). To explain why this is the case, FIG. 2 is a simplifiedblock diagram of a MCM data model 200 that is conventionally used bysuch existing systems for representing the cluster infrastructure of anorganization and tracking how organizational users map to theorganization's infrastructure resources for management access/control.In this example, the organization (i.e., “organization O”) includes fourKubernetes clusters C1, C2, C3, and C4 that are part of two clustergroups CG1 and CG2. Cluster groups CG1 and CG2 may correspond todifferent business units in organization O or any other logical groupingof clusters used by the organization. In addition, each clusterC1/C2/C3/C4 includes a corresponding namespace N1/N2/N3/N4.

As shown in FIG. 2, MCM data model 200 is organized according to a treehierarchy in which organization O is represented by a first-level (i.e.,root) organization node 202, cluster groups CG1 and CG2 are representedby second-level cluster group nodes 204 and 206 directly beloworganization node 202, clusters C1-C4 are represented by third-levelcluster nodes 208-214 directly below their respective cluster groupnodes 204/206, and namespaces N1-N4 are represented by fourth-level(i.e., leaf) namespace nodes 216-222 directly below their respectivecluster nodes 208-214. Further, various IT staff members of organizationO are bound to security roles at certain nodes of MCM data model 200,thereby granting those IT staff members authority to carry outmanagement tasks associated with the security roles for those respectivenodes/resources (as well as for all descendant nodes/resources in thehierarchy). For example, an IT staff member named “IT_UserA” is bound toan organization administrator (“org.admin”) security role via auser-role binding 224 (“[IT_UserA:org.admin]”) at organization node 202,which indicates that IT_UserA is authorized to perform all of themanagement tasks enabled by this role with respect to organization O andthe descendant resources of O in the hierarchy (i.e., cluster groups CG1and CG2, clusters C1-C4, and namespaces N1-N4). In addition, an IT staffmember named “IT_UserB” is bound to a cluster group administrator(“cg.admin”) security role via a user-role binding 226(“[IT_UserB:cg.admin]”) at cluster group node 204, which indicates thatIT_UserB is authorized to perform all of the management tasks enabled bythis role with respect to cluster group CG1 and the descendant resourcesof CG1 in the hierarchy (i.e., clusters C1 and C2 and namespaces N1 andN2).

The problems with employing a conventional MCM data model like model 200of FIG. 2 in the context of the previously-mentioned scenario ofdevelopment team T/multi-cluster application A are twofold: first,because only IT staff members are assigned and bound to security rolesin the MCM data model for the purposes of enabling infrastructuremanagement, it is not possible for development team T to independentlycreate and manage namespaces for multi-cluster application A; instead,development team T must request help from the IT staff member(s) thathave the appropriate roles/permissions assigned to them via the datamodel, and those IT staff member(s) must then perform the tasks onbehalf of team T, which is time-consuming and inefficient.

Second, because organizational users can only carry out management tasksthat align with the rigid organization→clustergroups→clusters→namespaces hierarchy shown in FIG. 2, it is not possiblefor users to operate on namespaces that belong to different Kubernetesclusters as a single logical unit. Thus, for instance, if a given accesspolicy needs to be applied to N namespaces that each belong to adifferent cluster, this cannot be achieved via a single operation.Instead, the access policy must be applied to each of the N namespacesindividually, which is burdensome and prone to errors.

To address the foregoing and other similar issues, FIG. 3 depicts anarchitecture 300 for MCM system 102 of FIG. 1 that includes a novelworkspace-enabled MCM data model 302 and a series of related workflows304. In various embodiments, workspace-enabled MCM data model 302 caninclude a hierarchy of infrastructure (e.g., organization, clustergroup, cluster, and namespace) nodes that is similar to conventional MCMdata model 200 of FIG. 2. However, in addition to these infrastructurenode types, workspace-enabled MCM data model 302 can include a new“workspace” node type, where a workspace is a logical grouping ofnamespaces that can belong to any of an organization's clusters.Further, workspace-enabled MCM data model 302 can allow the binding ofan organization's development team members to security roles atworkspace nodes.

By way of example, FIG. 4 depicts a workspace-enabled version (400) ofconventional MCM data model 200 of FIG. 2. As shown in FIG. 4,workspace-enabled version 400 includes a new workspace node 402 underorganization node 202 that groups together namespaces N1-N4 acrossdisparate clusters C1-C4 into a single management entity (i.e.,“workspace WS”). In addition, a development team member “DEV_UserA” isbound to a workspace administrator (“ws.admin”) security role via auser-role binding 404 (“[DEV_UserA:ws.admin]”) at workspace node 402,indicating that DEV_UserA can perform management tasks enabled by thisrole (which may include, e.g., adding/removing namespaces to theworkspace, applying policies, etc.) with respect to workspace WS and itschild/member namespaces N1, N2, N3, and N4.

With workspace-enabled MCM data model 302 in place, at the timepreviously-discussed development team T of organization 106 initiatesdevelopment of multi-cluster application A, (1) a new workspace for A(e.g., “workspace WS_A”) can be created and added, in the form of aworkspace node, to data model 302, and (2) a member of development teamT, such as a team lead or manager, can be assigned as an administratorof workspace WS_A by defining and attaching an appropriate user-rolebinding for that development team member to WS_A's node in the datamodel. Then, as work on multi-cluster application A progresses, theworkspace administrator can, e.g., create and add new namespaces toworkspace WS_A, set access/image/network policies on WS_A, and carry outother workspace/namespace-related management tasks with respect to WS_Avia workflows 304 of MCM system 102.

Significantly, because the workspace administrator is granted authorityto manage workspace WS_A via workspace-enabled MCM data model 302, theworkspace administrator does not need to request help from theorganization's IT staff in order to carry out these tasks; instead, theworkspace administrator (and thus development team T) can execute thetasks in a mostly independent, self-service manner (shown via referencenumeral 306). At the same time, because the workspace administrator'smanagement authority extends only to workspace WS_A and its membernamespaces, the workspace administrator is prevented from making changesto organization 106's cluster infrastructure (e.g., cluster groups andclusters), which remain the domain of the IT department (shown viareference numeral 308).

Further, because workspaces can group together namespaces from differentKubernetes clusters (which is not possible via the infrastructurehierarchy of conventional MCM data model 200), any namespace policies orfeatures that are applied to workspace WS_A will be automaticallyapplied to all member namespaces, regardless of which clusters thosemember namespaces belong to. This advantageously ensures consistent,correct, and timely application of those features/policies across all ofthe member namespaces.

The remaining sections of the present disclosure provide additionaldetails regarding the various workspace-related workflows 304 that maybe supported by MCM system 102 of FIG. 3, including workflows forcreating a new workspace, creating and adding a namespace to aworkspace, and setting an access policy on a workspace. It should beappreciated that FIGS. 1-4 are illustrative and not intended to limitembodiments of the present disclosure. For example, although FIG. 1depicts only a single organization 106 using MCM system 102, in otherembodiments multiple organizations may rely on system 102 in order tomanage their respective Kubernetes cluster fleets. In these embodiments,MCM system 102 can maintain a separate workspace-enabled MCM data modelfor each organization.

Further, although workspace-enabled MCM data model 400 shown in FIG. 4depicts only a single workspace for illustration, the embodiments of thepresent disclosure can support any number of workspaces in anorganization's data model. For an organization with a large andmulti-layered development org structure, the organization's workspacesmay be arranged in a nested fashion, such that some workspaces arecreated as children of other workspaces in the data model hierarchy.This can enable, e.g., the workspace administrator of a parent workspaceto manage all of the namespaces in its descendant workspaces, as well ascreate new workspaces under that parent workspace.

3. Workspace Creation

FIG. 5 depicts a workspace creation workflow 500 that may be implementedby MCM system 102 of FIG. 3 with respect to organization 106 accordingto certain embodiments. Workflow 500 can be initiated by an organizationadministrator or some other user within organization 106 that has theauthority to create and add new workspaces to the organization'sworkspace-enabled MCM data model 302.

Starting with block 502, MCM system 106 can receive (from, e.g., theorganization administrator) a request to create a new workspace for acontainerized application to be developed by a development team oforganization 106, where the request includes information such as theworkspace name and the user name/ID of a development team member thatwill be assigned as the administrator of the workspace.

In response, MCM system 102 can create the workspace using the providedname and add a node for the newly created workspace to workspace-enabledMCM data model 302 (under, e.g., the root-level organization node)(block 504). Note that because no namespaces have been added to thisworkspace yet, the workspace node will not be initially linked to anynamespaces in data model 302.

In addition, at block 506, MCM system 102 can create a user-role bindingthat associates the development team member specified in the workspacecreation request to a workspace administrator security role. This rolecan include permissions for, e.g., editing a workspace,adding/editing/removing namespaces on the workspace, applyingaccess/image/network policies to the workspace and its membernamespaces, and others.

Finally, at block 508, MCM system 102 can attach the user-role bindingto the workspace node added at block 504, thereby granting thatdevelopment team member all of the permissions in the workspaceadministrator role for the newly created workspace.

4. Creating and Adding a Namespace to a Workspace

FIG. 6 depicts a workflow 600 that may be implemented by MCM system 102of FIG. 3 for creating a new namespace in a Kubernetes cluster 104 oforganization 106 and adding that namespace to a workspace according tocertain embodiments. Workflow 600 assumes that a workspace administratorhas been assigned to the workspace per workflow 500 of FIG. 5. Workflow600 also assumes that the workspace administrator has been grantedauthority to create namespaces in cluster 104 (via, e.g., a “namespacecreator” security role) from an appropriate IT staff member of theorganization.

Starting with block 602, MCM system 102 can receive, from the workspaceadministrator, a request to create the new namespace in cluster 104 andto add the namespace to the administrator's workspace. This request caninclude information specifying a name for the new namespace and a nameor identifier of the workspace.

In response, MCM system 102 can transmit a command to cluster 104requesting creation of the namespace within the cluster (block 604).Upon receiving an acknowledgment from the cluster indicating that thenamespace has been successfully created, MCM system 102 can add a nodefor the new namespace to the organization's workspace-enabled MCM datamodel 302 and establish a link from the workspace node to the newnamespace node, thereby adding the namespace to the workspace (block606).

Finally, at block 608, MCM system 102 can synchronize any namespacepolicies that have been set for the workspace to the newly addednamespace. These polices can include, e.g., access policies specifyinguser-role bindings for members of the workspace administrator'sdevelopment team, image policies for controlling which imagerepositories may be used to download container images to a namespace,and network policies for controlling what network traffic is allowed toflow into or out of applications deployed in a namespace. The specificmanner in which the synchronization at block 608 can be performed withrespect to access policies is discussed in the next section.

5. Setting an Access Policy on a Workspace

FIG. 7 depicts a workflow 700 that may be implemented by MCM system 102of FIG. 3 for setting an access policy on a workspace according tocertain embodiments. Workflow 700 assumes that a workspace administratorhas been assigned to the workspace per workflow 500 of FIG. 5 and thatone or more namespaces have been added to the workspace per workflow 600of FIG. 6.

As used herein, an “access policy” is a collection of user-rolebindings. Thus, by defining an access policy that includes bindings forassociating development team members with “namespace view/edit” securityroles and setting that access policy on a workspace, a workspaceadministrator can grant those development team members view/edit accessto all of the member namespaces included the workspace (and thus allowthose team members to, e.g., view and edit configuration settings withineach namespace, deploy application objects to each namespace, and soon).

Starting with block 702, MCM system 102 can receive, from the workspaceadministrator, an access policy to be the applied to the workspace,where the access policy includes user-role bindings as indicated above.

At blocks 704 and 706, MCM system 102 can synchronize the access policyto the member namespaces of the workspace by translating the accesspolicy into a native format understood by Kubernetes (e.g., a role-basedaccess control (RBAC) policy) and transmitting the native policy to eachcluster of organization 106 that includes a member namespace of theworkspace.

Finally, at block 708, each cluster that receives the native policy canapply the policy to its respective namespace and thereby cause theuser-role bindings included in the policy to be activated on thatnamespace.

Certain embodiments described herein can employ variouscomputer-implemented operations involving data stored in computersystems. For example, these operations can require physical manipulationof physical quantities—usually, though not necessarily, these quantitiestake the form of electrical or magnetic signals, where they (orrepresentations of them) are capable of being stored, transferred,combined, compared, or otherwise manipulated. Such manipulations areoften referred to in terms such as producing, identifying, determining,comparing, etc. Any operations described herein that form part of one ormore embodiments can be useful machine operations.

Yet further, one or more embodiments can relate to a device or anapparatus for performing the foregoing operations. The apparatus can bespecially constructed for specific required purposes, or it can be ageneral-purpose computer system selectively activated or configured byprogram code stored in the computer system. In particular, variousgeneral-purpose machines may be used with computer programs written inaccordance with the teachings herein, or it may be more convenient toconstruct a more specialized apparatus to perform the requiredoperations. The various embodiments described herein can be practicedwith other computer system configurations including handheld devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.

Yet further, one or more embodiments can be implemented as one or morecomputer programs or as one or more computer program modules embodied inone or more non-transitory computer readable storage media. The termnon-transitory computer readable storage medium refers to any datastorage device that can store data which can thereafter be input to acomputer system. The non-transitory computer readable media may be basedon any existing or subsequently developed technology for embodyingcomputer programs in a manner that enables them to be read by a computersystem. Examples of non-transitory computer readable media include ahard drive, network attached storage (NAS), read-only memory,random-access memory, flash-based nonvolatile memory (e.g., a flashmemory card or a solid-state disk), a CD (Compact Disc) (e.g., CD-ROM,CD-R, CD-RW, etc.), a DVD (Digital Versatile Disc), a magnetic tape, andother optical and non-optical data storage devices. The non-transitorycomputer readable media can also be distributed over a network coupledcomputer system so that the computer readable code is stored andexecuted in a distributed fashion.

Finally, boundaries between various components, operations, and datastores are somewhat arbitrary, and particular operations are illustratedin the context of specific illustrative configurations. Otherallocations of functionality are envisioned and may fall within thescope of the invention(s). In general, structures and functionalitypresented as separate components in exemplary configurations can beimplemented as a combined structure or component. Similarly, structuresand functionality presented as a single component can be implemented asseparate components.

As used in the description herein and throughout the claims that follow,“a,” “an,” and “the” includes plural references unless the contextclearly dictates otherwise. Also, as used in the description herein andthroughout the claims that follow, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

The above description illustrates various embodiments along withexamples of how aspects of particular embodiments may be implemented.These examples and embodiments should not be deemed to be the onlyembodiments and are presented to illustrate the flexibility andadvantages of particular embodiments as defined by the following claims.Other arrangements, embodiments, implementations and equivalents can beemployed without departing from the scope hereof as defined by theclaims.

What is claimed is:
 1. A method for managing namespaces in amulti-cluster management system, the method comprising: creating, by acomputer system executing the multi-cluster management system, aworkspace for an application being developed by a software developmentteam of an organization, wherein the workspace is a logical grouping ofnamespaces on which the application has been or will be deployed, andwherein at least a subset of the namespaces can belong to differentclusters of the organization; and assigning, by the computer system, amember of the development team as a workspace administrator of theworkspace, the assigning enabling the member of the development team toperform one or more management tasks on the workspace and the namespacesvia the multi-cluster management system.
 2. The method of claim 1wherein the one or more management tasks include a task for creating anew namespace in a cluster of the organization and adding the newnamespace to the workspace.
 3. The method of claim 2 wherein, uponadding the new namespace to the cluster, the computer systemautomatically synchronizes namespace policies set on the workspace tothe new namespace.
 4. The method of claim 3 wherein the namespacepolicies include access policies, image policies, and network policies.5. The method of claim 1 wherein the one or more management tasksinclude a task for setting an access policy on the workspace, the accesspolicy including at least one or more user-role bindings that enable oneor more other members of the development team to access the namespacesin the workspace.
 6. The method of claim 5 wherein, upon receiving theaccess policy from the workspace administrator, the computer systemtranslates the access policy into a native format understood by theclusters of the organization and transmits the translated policy to eachcluster to which the namespaces in the workspace belong.
 7. The methodof claim 1 wherein the assigning of the member of the development teamas the workspace administrator enables the member to perform the one ormore management tasks without assistance from IT (informationtechnology) staff of the organization.
 8. A non-transitory computerreadable storage medium having stored thereon program code executable bya computer system executing a multi-cluster management system, theprogram code embodying a method for managing namespaces in themulti-cluster management system, the method comprising: creating aworkspace for an application being developed by a software developmentteam of an organization, wherein the workspace is a logical grouping ofnamespaces on which the application has been or will be deployed, andwherein at least a subset of the namespaces can belong to differentclusters of the organization; and assigning a member of the developmentteam as a workspace administrator of the workspace, the assigningenabling the member of the development team to perform one or moremanagement tasks on the workspace and the namespaces via themulti-cluster management system.
 9. The non-transitory computer readablestorage medium of claim 8 wherein the one or more management tasksinclude a task for creating a new namespace in a cluster of theorganization and adding the new namespace to the workspace.
 10. Thenon-transitory computer readable storage medium of claim 9 wherein, uponadding the new namespace to the cluster, the computer systemautomatically synchronizes namespace policies set on the workspace tothe new namespace.
 11. The non-transitory computer readable storagemedium of claim 10 wherein the namespace policies include accesspolicies, image policies, and network policies.
 12. The non-transitorycomputer readable storage medium of claim 8 wherein the one or moremanagement tasks include a task for setting an access policy on theworkspace, the access policy including at least one or more user-rolebindings that enable one or more other members of the development teamto access the namespaces in the workspace.
 13. The non-transitorycomputer readable storage medium of claim 12 wherein, upon receiving theaccess policy from the workspace administrator, the computer systemtranslates the access policy into a native format understood by theclusters of the organization and transmits the translated policy to eachcluster to which the namespaces in the workspace belong.
 14. Thenon-transitory computer readable storage medium of claim 8 wherein theassigning of the member of the development team as the workspaceadministrator enables the member to perform the one or more managementtasks without assistance from IT (information technology) staff of theorganization.
 15. A computer system executing a multi-cluster managementsystem, the computer system comprising: a processor; and anon-transitory computer readable medium having stored thereon programcode that, when executed by the processor, causes the processor to:create a workspace for an application being developed by a softwaredevelopment team of an organization, wherein the workspace is a logicalgrouping of namespaces on which the application has been or will bedeployed, and wherein at least a subset of the namespaces can belong todifferent clusters of the organization; and assign a member of thedevelopment team as a workspace administrator of the workspace, theassigning enabling the member of the development team to perform one ormore management tasks on the workspace and the namespaces via themulti-cluster management system.
 16. The computer system of claim 15wherein the one or more management tasks include a task for creating anew namespace in a cluster of the organization and adding the newnamespace to the workspace.
 17. The computer system of claim 16 wherein,upon adding the new namespace to the cluster, the computer systemautomatically synchronizes namespace policies set on the workspace tothe new namespace.
 18. The computer system of claim 17 wherein thenamespace policies include access policies, image policies, and networkpolicies.
 19. The computer system of claim 15 wherein the one or moremanagement tasks include a task for setting an access policy on theworkspace, the access policy including at least one or more user-rolebindings that enable one or more other members of the development teamto access the namespaces in the workspace.
 20. The computer system ofclaim 19 wherein, upon receiving the access policy from the workspaceadministrator, the computer system translates the access policy into anative format understood by the clusters of the organization andtransmits the translated policy to each cluster to which the namespacesin the workspace belong.
 21. The computer system of claim 15 wherein theassigning of the member of the development team as the workspaceadministrator enables the member to perform the one or more managementtasks without assistance from IT (information technology) staff of theorganization.